The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A computer network is a geographically distributed collection of interconnected communication links used to transport data between nodes, such as computers. Many types of computer networks are available, with the types ranging from local area networks to wide area networks. The nodes typically communicate by exchanging discrete packets or messages of data according to pre-defined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Computer networks may be further interconnected by an intermediate node, such as a switch or router, to extend the effective “size” of each network. Since management of a large system of interconnected computer networks can prove burdensome, smaller groups of computer networks may be maintained as routing domains or autonomous systems. The networks within an autonomous system (AS) are typically coupled together by conventional “intradomain” routers. Yet it still may be desirable to increase the number of nodes capable of exchanging data; in this case, interdomain routers executing interdomain routing protocols are used to interconnect nodes of the various ASs.
An example of an interdomain routing protocol is the Border Gateway Protocol version 4 (BGP4), which performs routing between autonomous systems by exchanging routing information, e.g., network layer reachability information (NLRI), among neighboring interdomain routers of the systems. An adjacency is a relationship formed between selected neighboring (peer) routers for the purpose of exchanging routing information messages and abstracting the network topology. Before transmitting such messages, however, the peers cooperate to establish a logical “peer” connection (session) between the routers. BGP4 establishes reliable connections/sessions using a reliable/sequenced transport protocol, such as the Transmission Control Protocol (TCP).
The NLRI information exchanged by BGP peers typically includes destination address prefixes, i.e., the portions of destination addresses used by the routing protocol to render routing (“next hop”) decisions. An example of such a destination address is the Internet Protocol (IP) version 4 (IPv4) address. A prefix implies a combination of an IP address and a mask that cooperate to describe an area of the network that a peer can reach. Each prefix may have a number of associated paths; each path is announced to a peer router by one or more of its peers. Note that the combination of a set of path attributes and a prefix is referred to as a “route”; the terms “route” and “path” may be used interchangeably herein. The BGP4 routing protocol standard is well known and is described in Request For Comments (RFC) 1771, by Y. Rekhter and T. Li (1995), Internet Draft <draft-ietf-idr-bgp4-23.txt> titled, A Border Gateway Protocol 4 (BGP-4) by Y. Rekhter and T. Li (April 2003) and Interconnections, Bridges and Routers, by R. Perlman, published by Addison Wesley Publishing Company, at pages 323-329 (1992), all disclosures of which are hereby incorporated by reference.
BGP4 is generally capable of only carrying routing information for IPv4; accordingly, a multi-protocol extension to BGP4, referred to as BGP4+, extends BGP4 to allow carrying of routing information for multiple network layer protocols, such as IP version 6 (IPv6) and Internetwork Packet Exchange (IPX) addresses. BGP4+ extends BGP4 to associate these network layer protocols with next hop information and NLRI. Address Family Identifiers (AFIs) and Subsequent Address Family Identifiers (SAFIs) are used to identify the network layer protocols. BGP4+ and AFI/SAFI Address Family are well known and described in RFC 2858, by T. Bates et al. (2000) and RFC 1700 by J. Reynolds et al (1994), which are hereby incorporated by reference.
The interdomain routers configured to execute an implementation of the BGP protocol, referred to herein as BGP routers, perform various routing functions, including transmitting and receiving routing messages and rendering routing decisions based on routing metrics. The BGP protocol executing on each BGP router may be organized as a plurality of address family application modules, each of which is configured to provide an AFI/SAFI service such as IPv4/unicast, IPv4/multicast, IPv6/unicast or IPv6/multicast. Each AFI/SAFI service is enabled on a per peer basis by exchanging capabilities over the reliable BGP session between the router and its peer in accordance with Capabilities Advertisement with BGP4 described in RFC 3392 by R. Chandra et al (November 2002), which is hereby incorporated by reference. Two or more services may be enabled for two or more AFI/SAFI modules over the same BGP session and reliable transport.
Each BGP router also maintains a routing table that lists all feasible paths from that router to a particular network. The routing table is a database that contains routing information used to construct a forwarding table of a forwarding information base (FIB) that is used by the router when performing forwarding decisions on packets. Periodic refreshing of the routing table is generally not performed; however, BGP peer routers residing in the ASs exchange routing information under certain circumstances. For example, when a BGP router initially connects to the network, the peer routers exchange the entire contents of their routing tables. Thereafter when changes occur to those contents, the routers exchange only those portions of their routing tables that change in order to update their BGP peers' tables. These Update messages are thus incremental update messages sent in response to changes to the contents of the routing tables and announce only a best path to a particular network.
Broadly stated, a BGP router generates Update messages for an adjacency, also known as a peer router, by “walking-through” the routing table and applying appropriate routing policies. A routing policy is information that enables a BGP router to rank routes according to filtering and preference (i.e., the “best path”). Routing updates provided by the Update messages allows BGP routers of the ASs to construct a consistent view of the network topology. The Update messages are typically sent using a reliable transport, such as TCP, to ensure reliable delivery. TCP is a transport protocol implemented by a transport layer of the IP architecture; the term TCP/IP is commonly used to denote this architecture. The TCP/IP architecture is well known and described in Computer Networks, 3rd Edition, by Andrew S. Tanenbaum, published by Prentice-Hall (1996).
In particular, BGP peer routers use the Update messages to exchange routing information that is qualified by both AFI, such as IPv4, IPv6 or other address families, and SAFI, such as unicast, multicast or other applications, over a reliable BGP session. Often, an event may arise wherein a network administrator resets the BGP session for administrative reasons, e.g., to upgrade or enable a service of an AFI/SAFI module, or an error condition occurs with the module. The peers typically communicate the occurrence of the event or error condition through a conventional BGP Notification Message. However, a problem with the conventional Notification message is that it resets the BGP session (including reset of all the AFI/SAFI module services) and terminates the reliable transport between the routers. Thus, an event or error associated with one AFI/SAFI service provided over the transport penalizes all other services provided over that transport, resulting in routing “flaps” (streams of Update messages) for all AFI/SAFI modules supported by the peers.
One solution to this problem involves configuring multiple BGP sessions, one for each AFI/SAFI module or set of AFI/SAFI modules, between the peer routers. Each BGP session operates over a reliable (TCP connection) transport, typically by configuring multiple network layer (IP) addresses on each router and binding each session to a different IP address. Another solution involves multi-session BGP, wherein each of a plurality of BGP sessions is configured for each AFI/SAFI module or set of AFI/SAFI modules between a pair of BGP router peers. Here, rather than binding each session to a different IP address on each router, this approach shares an IP address over different sessions. However, each solution consumes resources (e.g., TCP bandwidth and associated control processing) that could be allocated more efficiently in the routers.
A related problem is that whenever a BGP session or an AFI/SAFI is reset, a BGP router flushes all the routes for that AFI/SAFI. When the routes are flushed, the router cannot forward traffic on those routes. However, the cause of the AFI/SAFI reset may not have affected the state of the routes in the Adj-RIB. This is especially true when the cause of the reset is expiration of a timer, exceeding the max-prefix-limit, etc. In these cases, a BGP protocol module may normally seek to reset all prefixes, but it is unnecessary to disrupt the forwarding plane for all prefixes due to the soft-reset of the AFI/SAFI.